What does this PR do?

Fixes test create-batch --run without --wait always exiting 1 even when every trigger succeeds — which broke the documented exit-code contract and failed CI pipelines on fully successful dispatches.

The no-wait path returns each result with the trigger response's status, which is queued by design (the field is documented as "Terminal status if --wait; queued if no --wait"). But the exit-code logic only recognized terminal statuses:

const allPassed = batchRunResults.every(r => r.status === 'passed'); // queued → false
if (allPassed) return;
...
throw new CLIError(`Batch run finished: ${...} of ${...} run(s) did not pass.`, 1);

Every no-wait result is queued, so allPassed was always false and the command fell through to exit 1 with a misleading "N of N run(s) did not pass" — even on a fully successful dispatch. It was also internally inconsistent: single test run <id> without --wait exits 0 on a successful queued dispatch.

Fix

In the no-wait case, "success" means every trigger was dispatched without error (statuses are non-terminal by definition). The exit-code block now branches on opts.wait:

const failing = opts.wait
  ? batchRunResults.filter(r => r.status !== 'passed')   // --wait: terminal 'passed'
  : batchRunResults.filter(r => r.error !== undefined);  // no --wait: dispatched OK
if (failing.length === 0) return; // exit 0

Trigger errors in no-wait mode keep today's aggregation (uniform specific code when shared, else exit 1), and the "did not pass" message becomes "N of N trigger(s) failed" when --wait is absent. The stderr text summary is likewise corrected for no-wait mode — it now reports N/N triggered instead of misreading a successful dispatch as 0/N passed. --wait semantics are unchanged.

Reproduction (before this PR)

testsprite test create-batch --plans ./plans.jsonl --run --output json
# stdout: results[] with every entry status:"queued", no errors
# stderr: "Batch run finished: 2 of 2 run(s) did not pass."
# exit code: 1  ← CI marks a fully successful dispatch as FAILED

Related issue

Fixes #161

Type of change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that changes existing behavior)
• Documentation only
• Build / CI / chore

Checklist

• PR targets the main branch.
• Commits follow Conventional Commits.
• npm run lint and npm run format:check pass.
• npm run typecheck passes.
• npm test passes and coverage stays above the 80% gate (1618 tests; 88.34% stmts / 85.42% branch).
• New behavior is covered by unit tests (mock-based; no network or credentials required).
• No secrets, API keys, internal endpoints, or personal data are included.
• User-facing changes are reflected in DOCUMENTATION.md (create-batch now documents the no-wait exit-0 contract, mirroring test run).

Notes for reviewers

• Three new specs in test.create-batch-run.spec.ts:
  • all-queued (--output json) → resolves without error and never polls (pollCount === 0);
  • all-queued (--output text) → summary reads 3/3 triggered, with no passed / did not pass wording;
  • partial trigger failure (2 queued + 1 NOT_FOUND) → still exits non-zero, full results envelope intact.
• The two success specs fail against the pre-fix exit-code block and pass with it (verified by reverting the source hunk); the partial-failure spec passes in both, guarding the error path. Existing no-wait specs only exercised error scenarios and never asserted the success exit code — which is how this slipped through.
• The change is scoped to the exit-code + text-summary block in runBatchRun; JSON output shape, --wait semantics, and all other exit codes (6/7/11) are unchanged.

Summary by CodeRabbit

• Bug Fixes

  • Improved test create-batch --run behavior when used without --wait.
  • Queued runs now report successful dispatches instead of being incorrectly treated as passed or failed.
  • Immediate trigger errors still produce a non-zero exit code while preserving successful and failed results in the output.
  • Text summaries now accurately show trigger counts and errors.

• Documentation

  • Clarified batching, waiting behavior, polling, and exit-code semantics.